Replaces `ink-select-input` with a hand-rolled select prompt built
on Ink's `useInput` hook directly. Same pattern as our existing
`MultiSelectPrompt` — same cursor glyph, same accent color, same
hint placement, same keyboard handling.

Why? `ink-select-input`'s items array is recreated on every parent
render, which races with its internal `useEffect` that resets
`selectedIndex` on items-change. Under our store-driven re-render
cadence (tip rotation every 8s, log lines, file-read updates) the
cursor never settled and arrow keys felt unresponsive — the user
reported the experimental-confirm prompt couldn't be navigated or
selected.

Doing the same `useInput`-based render that `MultiSelectPrompt`
already uses gives us:

  - Stable state across re-renders (cursor lives in our own
    `useState`, no externally-driven reset).
  - Consistent visual styling between single- and multi-select.
  - Escape-to-cancel handling. The bridge translates `resolve(null)`
    to the shared `CANCELLED` sentinel, so the wizard runner's
    cancellation path triggers cleanly.

Also drops `ink-select-input` and `ink-text-input` from devDeps
(both unused now) and updates the build/bundle externals lists.

Verification:
  - bun run typecheck (clean)
  - bun x ultracite check (1 pre-existing warning, no new ones)
  - bun test --isolate test/lib/init/ (227 pass)
  - SENTRY_CLIENT_ID=test bun run build (binary 108.79 MB,
    no size regression)
  - InkUI smoke test renders cleanly through the dispose path.

Root cause: a known Bun + Ink interaction bug
(oven-sh/bun#6862, vadimdemedes/ink#636, both still open). Ink's
`useInput` hook listens for `readable` events on its stdin
(default `process.stdin`) and pulls bytes via `stdin.read()`. Bun's
compiled binaries have a long-standing issue where the inherited
fd 0 accepts `setRawMode(true)` but never delivers `readable`
events for terminal input. So:

  - the wizard rendered fine (Ink's stdout writes are unaffected),
  - but arrow keys, Enter, and Ctrl+C all did nothing —
    `useInput` listeners never fired,
  - and "can't exit the program" because raw mode suppresses
    SIGINT delivery for Ctrl+C, and our SIGINT fallback handler
    never ran either.

Fix: open a fresh `/dev/tty` `tty.ReadStream` ourselves and pass
it to Ink as the `stdin` option. Fresh fds opened from inside the
process don't trigger the inheritance bug, so their `readable`
events fire correctly. Ink's `setRawMode(true)` on the fresh
stream toggles termios on the underlying TTY device — the same
device fd 0 points at — so the user's terminal still goes raw,
just via a different fd. We close the stream on dispose to
release the libuv handle.

Bonus fixes wrapped in:

  1. **Ctrl+C handling in raw mode.** Each prompt's `useInput`
     now treats `key.ctrl && input === "c"` as a cancel (same
     path as Esc). A top-level `useInput` in the App component
     handles Ctrl+C during spinners (no prompt mounted) by
     calling `process.exit(130)` so users can always abort.
  2. **Removed dead `forwardFreshTtyToStdin()` call.** The
     macOS-only workaround in `wizard-runner.ts` was clack-era
     dead code: `LoggingUI` doesn't read stdin (its prompts
     throw), and `InkUI` now opens its own /dev/tty. The
     function is preserved in `stdin-reopen.ts` for future
     callers but no longer wired in. This also removes a class
     of conflicts where the workaround's no-op `_read` and
     data-event forwarding actively broke Ink's stdin reading
     on macOS.
  3. **Stdin teardown.** `InkUI.[Symbol.asyncDispose]` now
     calls `setRawMode(false)` and `destroy()` on the fresh
     stream so the user's shell isn't left in raw mode if the
     wizard crashes mid-prompt.

Verification:
  - bun run typecheck (clean)
  - bun x ultracite check (1 pre-existing warning, no new ones)
  - bun test --isolate test/lib/init/ (227 pass)
  - SENTRY_CLIENT_ID=test bun run build (binary 108.79 MB,
    no size regression)
  - Binary smoke (init --help) renders cleanly.
  - Embedded ink-app.tsx + new openFreshTtyForInk helper visible
    in compiled binary's strings dump.

Caveats this fix carries forward:
  - Still requires `react-devtools-core` as a devDep so
    Bun.compile can resolve Ink's static reference (gated behind
    `process.env.DEV === "true"` at runtime, dead code in prod).
  - macOS-only force-exit timer in `init.ts` still fires after
    runWizard returns to drain the libuv handle for our fresh
    /dev/tty stream (same root cause as before, just different
    fd source). Comment updated to reflect the new owner.

Two visual fixes called out by the user:

1. **Clear the wizard chrome before printing the post-dispose
   summary.** Previously the bordered wizard box stayed on screen
   above the chalk summary, which was redundant and visually
   noisy. `instance.clear()` now runs immediately before `unmount()`
   so Ink rewinds the cursor and overwrites the rendered region;
   the post-dispose `Setup complete` line + summary becomes the
   only thing left on screen. The summary now writes to stdout
   (was stderr) so it lands in the same stream as the cleared
   Ink output — avoids potential interleave issues when the user
   pipes stdout/stderr separately.

2. **Tighten sidebar spacing.** The three sidebar panels
   (TipPanel, ProgressPanel, FilesPanel) had a `gap={1}` between
   them, plus 1-row inner margins between each panel's title and
   body. That was ~7 wasted rows on a typical run. Removed:
     - The outer `gap={1}` between panels (now flush borders).
     - `marginBottom={1}` after each panel title.
     - `marginTop={1}` between TipPanel body and counter.
   Tip-card body and counter are now stacked directly via the
   normal flex flow; the rounded border + `paddingX={1}` already
   provides enough visual separation. The `Did you know?` heading
   moved into the bottom counter row (`Tip 3 of 12 · Did you
   know?`) so the title row isn't wasted on a static label that
   never changed.

3. **Better files-panel truncation indicator.** The "scroller"
   the user asked for can't be a real interactive scroller —
   Ink doesn't ship a scrollbox primitive, the file tree updates
   frequently (new reads push the bottom), and adding `useInput`
   to the panel would compete with the active prompt for key
   events. Instead the tail-window UX is preserved with a
   clearer indicator: `↑ N earlier (scrolled)` at the top when
   rows are off-screen, and the panel header already shows
   `Files analyzed (n/total)` so the user sees the full count.
   Reserving 1 row for the header inside the maxRows budget
   means the actual file-row count is honoured (previously the
   header could squeeze the last visible file row).

Verification:
  - bun run typecheck (clean)
  - bun x ultracite check (1 pre-existing warning, no new ones)
  - bun test --isolate test/lib/init/ (227 pass)
  - SENTRY_CLIENT_ID=test bun run build (binary 108.79 MB,
    no size regression)
  - Smoke test confirmed: post-dispose summary stands alone,
    no wizard box above it.

Sweep the surrounding init/ files (everything except ink-ui.ts and
ink-app.tsx, where OpenTUI references intentionally document
history) so doc comments accurately describe the current Ink-based
implementation. No behavior changes.

Touched files:
- clack-utils.ts: sidebar comment refs
- formatters.ts: header explaining why summary is structured data
- git.ts, interactive.ts: paths through WizardUI
- types.ts (init): forceLegacyUi rationale
- ui/file-tree.ts: tree builder's two consumers
- ui/logging-ui.ts: tree-row format docstring
- ui/sentry-tips.ts: where tips render
- ui/types.ts: WizardSummary, banner, summary, recordFilesReading,
  setStep doc rewrites
- wizard-runner.ts: header + four inline references

Adds `test/lib/init/ui/ink-app.snapshot.test.tsx` — four smoke tests
that mount the React tree directly via Ink's `render()` API with a
captured `Writable` stream, then assert against the rendered frames:

1. **Banner + sidebar at 120 cols.** Verifies the box-drawing
   banner renders, the sidebar's three panels (`Did you know?`,
   `Progress`, file tree) appear, and live log/spinner content
   reaches the frame.

2. **Sidebar hides at 80 cols.** Confirms `SIDEBAR_BREAKPOINT`
   gating works — banner + log render but the panel headers are
   absent.

3. **Divider tracks main-column width.** Asserts the new
   `Divider` component grows up to 56 cols on an 80-col terminal
   (vs. the old hard-coded 50). Picks the second-longest unique
   `─` run length to skip the outer wizard chrome border.

4. **Ctrl+C path uses requestCancel.** Smoke-checks that
   `WizardStore.setRequestCancel` round-trips correctly so the
   App's top-level `useInput` handler can route Ctrl+C through
   the bridge's idempotent teardown rather than calling
   `process.exit(130)` directly.

Why mount Ink directly instead of spawning the binary?
Bun-compiled standalone binaries report `process.stdin.isTTY:
false` even when launched through `script(1)` or a hand-allocated
`/dev/ptmx` pair (verified via `dlopen("libc.so.6")` +
`posix_openpt` from a driver script). The `factory.ts`
TTY check therefore routes to `LoggingUI` and prompts throw
`LoggingUIPromptError` before any visual work happens. Mounting
the React tree directly via Ink's `render()` API sidesteps that
detection and exercises the actual visual contract.

The `CaptureStream` writable concatenates every chunk Ink emits
(it splits a render across cursor moves + sync flag + content +
sync unflag — the last chunk alone is usually a control
sequence). The `makeStdin()` shim implements just enough of the
`ReadStream` surface for Ink's raw-mode toggling.

All 6337 tests pass (+4 new); biome lint clean (1 pre-existing
warning unchanged).

Restores the scrollable Files Analyzed sidebar that the OpenTUI
implementation had via `<scrollbox stickyStart="bottom">`. Ink
doesn't ship a scrollbox primitive, so this is a hand-rolled
component with two improvements over the auto-only OpenTUI version:

1. **Visual scrollbar.** A 1-column track of `│` glyphs on the
   right edge of the panel, with a `█` thumb whose position +
   size reflects the visible window's place in the full
   read-tree. Shown only when content exceeds the viewport;
   hidden when everything fits.

2. **Keyboard scroll-back.** While no prompt is mounted (gated
   on `!hasActivePrompt` so it never fights a select/multiselect's
   own `useInput`):
   - ↑ / ↓        — scroll one row
   - PgUp / PgDn  — scroll one viewport
   - Home         — jump to oldest entry
   - End / Esc    — re-pin to latest (auto-follow)

Auto-follow ("pinned to bottom") is the default — newly-read
files always come into view, like `tail -f`. The user can scroll
back; while unpinned, new file arrivals don't shift the visible
window (the panel bumps `offset` by the new-row count to keep
the view stable). Pressing PgDn / ↓ until offset reaches 0
re-pins automatically, so the user doesn't need to remember to
press End.

Architecture:
- Scroll state (`pinnedToBottom`, `offset`) is React `useState`
  inside FilesPanel — UI concern, not wizard-store domain.
- A `useEffect` watching `totalRows` handles three cases:
  arrival-while-unpinned (bump offset), shrink (clamp offset to
  new maxOffset), and pinned-to-bottom (no-op).
- Header shows a `↑ ` prefix on the counter when scrolled up,
  signaling the panel won't auto-follow.
- App threads `hasActivePrompt = snapshot.prompt !== null`
  through Sidebar to FilesPanel — single boolean, no
  refactoring of existing layout.

Tests:
- New snapshot test "FilesPanel renders scrollbar when content
  exceeds viewport" compares `█` counts between a few-files
  baseline and a many-files render. Banner ASCII art uses U+2588
  too, so exact-pattern matching can't distinguish thumb from
  banner — count-delta works around that.
- Header pinned-state regex confirms the `↑ ` prefix is absent
  when (default) the panel auto-follows.

Verification: 6338/6338 tests pass (+1 new), lint clean (1
pre-existing warning unchanged), binary at 108.80 MB
(unchanged).